人到中年，我才開始認真思考下一段職涯。
近期，我陸續取得了 PMP 與 PMI-ACP 證照，希望結合過去十多年的軟體開發經驗，朝 Technical Project Manager（技術專案經理） 的方向發展。
原本以為，十多年累積下來的系統開發、問題分析與專案實務，應該能成為轉型路上的穩固基礎。沒想到，生成式 AI 的快速發展，卻讓我產生了前所未有的危機感。
以前需要花好幾天研究、撰寫與除錯的程式，現在只要把需求描述清楚，AI 可能在幾分鐘內就能產生一個初步版本。
更讓人感到壓力的是，剛進入職場的新生代，從學習寫程式的第一天起，就已經開始使用 AI。他們查資料、整理需求、產生程式碼與撰寫文件時，很自然地就會把 AI 當成工作夥伴。
對他們而言，AI 不是轉型，而是日常。
反觀我們這些已經在職場打滾多年的老兵，面對迎面而來的 AI 巨浪，究竟該如何選擇？
是站在岸邊懷念過去熟悉的工作方式，還是學習如何駕馭這股浪潮？
又或者，還來不及反應，就被巨浪吞沒？
一個人，走完整條軟體交付流程
我目前的工作環境，經常需要提供「一條龍」服務。
身為一名 AP（Application Programmer），我的工作並不只是把程式寫完。從一個需求被提出，到功能正式上線並穩定運作，中間大大小小的工作幾乎都必須參與：

與使用者訪談、釐清需求
進行需求分析與系統規劃
評估開發時程、風險及系統相依性
設計與開發程式
執行單元測試與撰寫測試文件
安排與執行整合測試
協助使用者驗收測試（UAT）
整理缺陷、需求變更及測試結果
準備上版內容與發布通告
規劃上版 SOP
準備回復計畫（Rollback Plan）
執行部署與正式上線
進行上線後驗證
追蹤系統指標與後續監控

每一個環節都很重要，任何一個地方出現遺漏，都可能影響上線結果。
真正消耗時間的，往往不只是寫程式，而是散落在整個流程裡的行政與知識工作：整理會議紀錄、追蹤待辦事項、比對需求版本、撰寫測試案例、更新風險、準備進度報告，以及反覆確認每一個人的認知是否一致。
這些工作不能不做，卻會不斷切割專注力。
我經常忍不住想：

如果有一位助理，可以幫我整理資訊、檢查遺漏、追蹤風險，並準備文件初稿，那該有多好？

現在，這位助理或許不一定是一個人，也可能是一組 AI Skills。
AI 帶來危機，也帶來一位新助理
AI 的出現，對資深工程師而言既幸運，也有些不幸。
不幸的是，許多過去需要多年累積才能熟練的技術工作，如今可以在 AI 的協助下快速完成。只會按照規格寫程式，可能不再足以構成長期的職場優勢。
幸運的是，同一套技術也讓個人第一次有機會取得過去難以想像的生產力。
AI 已經可以協助敏捷團隊整理會議議程與紀錄、追蹤決策、分析 Sprint 進度、精煉使用者故事、拆解工作，以及產生測試資料。它也能自動處理重複性任務、分析專案資料、追蹤里程碑，並提供風險與資源配置方面的洞察。
這讓我逐漸意識到，問題或許不應該是：

AI 會不會搶走我的工作？

而應該改成：

我能不能把十多年的開發經驗、PMP 的專案治理觀念，以及 PMI-ACP 的敏捷方法，轉化成 AI 可以協助執行的工作流程？

當 AI 能快速產生程式碼，工程師的重心可能逐漸轉向需求判斷、架構設計、成果審查與決策；專案協調與跨團隊依賴管理的重要性也會隨之提升。
所以，我不打算和 AI 比誰寫程式比較快。
我真正需要培養的，是定義問題、補充情境、判斷風險、設計流程，以及驗證 AI 產出是否正確的能力。
我的 AI 助理，不只是一個聊天視窗
市面上已經有許多能回答問題、整理文件或產生程式碼的生成式 AI 工具。但在真實的專案環境中，只有「聊天」還不夠。
我希望打造的，是一套適合專案經理與技術專案人員使用的 PM AI 工具箱。
工具箱裡的每一項 Skill，都要對應一個明確的專案管理情境，例如：

把模糊需求整理成專案章程
將訪談紀錄轉換成使用者故事
依照 INVEST 原則檢查故事品質
產生 Given-When-Then 驗收條件
協助整理與排序 Product Backlog
檢查 Sprint 容量與工作安排
從會議紀錄擷取決策及 Action Items
找出專案風險、依賴與阻礙
分析需求變更可能造成的影響
產生測試案例與 UAT 檢查清單
整理上版 SOP 與 Rollback Plan
彙整專案健康度與每週進度報告

這些 Skill 不應只回傳一段看似合理的文字，而應具有明確的輸入、處理規則與結構化輸出。
更重要的是，每個 Skill 都必須保留「人工確認」的環節。
因為 AI 可以協助整理資料與提出建議，但無法代替專案經理承擔最後的決策責任。專案中的組織文化、政治因素、團隊情緒、資源限制與利害關係人期待，並不會只存在於一份需求文件裡。

從 Paper Prototyping 說起
過去參與敏捷專案時，曾經使用 Paper Prototyping 協助團隊探索需求。
當時，我們不急著立刻寫程式，而是先用紙張畫出操作介面，再邀請使用者實際演練。
使用者點下紙上的「按鈕」後，團隊成員便抽換下一張畫面；如果操作方式不符合預期，我們可以立刻修改，甚至直接重新畫一張。
這個方法看起來很陽春，卻非常有效。
它讓團隊能用很低的成本回答幾個重要問題：

使用者真正想解決的問題是什麼？
我們對需求的理解是否一致？
操作流程符合使用者習慣嗎？
哪些功能真的重要？
哪些設計只是團隊自己的想像？
哪些問題可以在開始開發前先被發現？

Paper Prototyping 的核心價值從來不在那幾張紙，而在於讓團隊提早與使用者互動，透過真實回饋反覆修正產品假設。
這正是敏捷強調的精神：不等待整個產品完成才收集意見，而是透過迭代、增量交付與持續回饋，讓產品逐步貼近使用者需求。
當 Paper Prototyping 遇上 Google Stitch
進入 AI 時代後，原型製作的成本又進一步降低了。
過去從紙上草圖進入 Wireframe，再從 Wireframe 製作 Mockup，經常需要經過多輪溝通。如果團隊缺乏專職 UI／UX 設計師，工程師可能還得一邊研究元件、一邊調整版面。
現在，我們可以嘗試使用 Google Stitch，透過文字描述或參考圖片產生網頁及 App 的 UI，並取得對應的前端程式碼。產生的結果還能匯出到 Figma，或交由開發者在 IDE 中繼續調整。

取得第一版介面後，便能立刻拿去和使用者討論

Google Stitch 並不代表我們可以省略使用者研究，也不代表 AI 產生的第一版設計就是正確答案。它的價值在於快速產生一個「可以被討論的具體成果」，降低從想法到原型之間的成本。
換句話說，AI 並沒有改變敏捷重視回饋的核心精神，而是讓我們能更快、更頻繁地取得回饋。